Lightweight Semantic-enabled Enterprise Service-Oriented Architecture

ion of services means that “service contracts only contain essential information and information about services is limited to what is published in service contracts”. Therefore, it is always a good practice to design services by hiding as much underlying details as possible. This assures and complements the previous loose coupling SOA principle. Therefore, the avoidance of providing any unneeded service information and meta-data is important in this principle (Erl, 2005). Reusability means that the services can “contain and express agnostic logic and can be positioned as reusable enterprise resources”. This means that the logic behind the services is designed to be reusable and highly generic. Moreover, the service contracts in this sense have to be extensible and generic as well and finally the services behind are designed to be reused and accessed simultaneously sectors (Dan et al., 2008). Autonomy or service independence means that the “services exercise a high level of control over their underlying runtime execution environment” (Erl, 2009). This means that services have to contain their logic apart of any external influence. In other words, services are designed to be more isolated. This increases service reliability and trigger its behavioral predictability (Daigneau, 2011, p. 15). Statelessness means that the services “minimize resource consumption by deferring the management of state information when necessary”. Hence, the deferral extensions management must be incorporated within service design to reach three goals: increasing service scalability, supporting agnostic logic design, and last but not least improving service reusability (Papazoglou, 2008, pp. 15–16). Discoverability is another important SOA principle. It indicates that “Services are supplemented with communicative meta-data by which they can be effectively discovered and interpreted”. Appropriate meta-data about the service’s purpose and capabilities are provided in service contracts. These contracts are designed to be discoverable to both humans and other service clients. To be discovered, the service contracts are normally published in one or more service registries (Arsanjani, 2004, p. 3; Bean, 2009, p. 37). Composability is the last SOA principle. It means that “Services are effective composition participants, regardless of the size and complexity of the composition”. As a design consideration, there is always high possibility that a service can join in various composition scenarios to produce new services that are able to solve bigger problems and this in turn boosts the reusability principle (Katzan Jr, 2008, p. 131). Chapter 3 Service-Oriented Architecture 39 The aforementioned principles make from Web Services good technology to overcome application and middleware heterogeneity problems. Next section explains the business value of SOA by introducing the concept of business-driven or enterprise SOA. 3.2 Enterprise SOA and Other Architectures Business-driven or enterprise SOA is merely representing the concept where bunch of independent services can be utilized efficiently in many styles to deliver multiple, highlevel business services and workflow-based business processes. To achieve this, a combination of technology and business is always required. Business services have to be composed out of other services published in an enterprise’s service repository. These business services have to be fit into the enterprise’s business model and to be effective part of it. The main goal of business models in enterprise SOAs is to create sets of services that can produce higher business values. If enterprise SOA is implemented without having a powerful business model, it will end up with bunch of incompatible services that have short lifetime. Therefore, business models have to have higher priorities at the design time to provide higher-level values to the enterprise SOA solutions (cf. Rosen et al., 2008, p. 43). The following two subsections compare enterprise SOA with Enterprise Architecture and Software Architecture respectively. This comparison is made mainly to show that SOA can be integrated with both architectures without having serious integration incompatibilities. 3.2.1 Enterprise Architecture Similar architecture to be compared with enterprise SOA is the Enterprise Architecture (EA). It is composed of several enterprise components that represent different business entities, their properties and the relationships among these components. EA divides enterprises into manageable pieces. These subdivisions can be architectural perspectives, views, domains, sub-architectures, or perspectives. Generally, EA can be broken down into business architecture, information architecture, application architecture, and technology architecture. Based on (Alwadain et al., 2011; Rosen et al., 2008, p. 44; Kistasamy, Van Der Merwe, & De La Harpe, 2010), there are a lot of similarities between EA and enterprise SOA. The similarities between these two architectures can be summarized as follows:  The business architecture of EA can be mapped to the business model of enterprise SOA. Chapter 3 Service-Oriented Architecture 40  The information architecture in EA can be mapped to the common semantics and data model of enterprise SOA or more precisely to its semantic information model.  The EA application architecture can be mapped to most of the enterprise SOAbased solutions including integration services and enterprise business processes.  The EA technology architecture can be mapped to the service bus of enterprise SOA and defines how the service infrastructure meets all SOA-related issues like distribution, binding, security, performance and so forth. As a conclusion and if an organization has applied an EA and wants to introduce enterprise SOA, there will be no big incompatibility in integrating EA and SOA based on the previous comparison as a supporting evidence. 3.2.2 Software Architecture Another architecture that can be compared with enterprise SOA is the Software Architecture. As defined by (Bass, Clements, & Kazman, 2003, p. 21), the Software Architecture is “the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them”. One of the most common Software Architecture approaches is the “4+1Views” approach that was primarily developed by Philippe Kruchten (Kruchten, 1995). This Software Architecture approach is composed of five views namely: logical, component, process, physical, and use cases views. The logical view includes the system’s object model supported by class, collaboration, and sequence diagrams. The component view includes the system’s files and dependencies supported by component diagrams. The process view includes the system’s processes and threads supported by deployment diagrams. The physical view includes the system’s applied network topologies and its diagrams. Finally and as its name indicates, the use case view includes the system’s main business scenarios supported by bunch of use case diagrams. The comparison between the Software Architecture and enterprise SOA is based on comparing SOA to the “4+1 Views” approach (Ionita, Florea, & Jelea, 2009; Rosen et al., 2008, pp. 49–50; Zimmermann, Koehler, & Leymann, 2006). This comparison can be summarized as follows:  The logical view map to the service design.  The component view maps to the main interactions between services.  The process and physical view map to the implementation of services using specific technologies and their deployment in specific infrastructures. Chapter 3 Service-Oriented Architecture 41  The use case view maps to the main scenarios of enterprise SOA that involve either single service or set of services.